feat!: generate stealth statements from wallet api+new sending test - #1620

applications/tari_walletd/src/handlers/helpers.rs (1)

150-152: LGTM! Improved error specificity.

The change to use .optional()?.ok_or_else(|| not_found(...)) provides clearer, more actionable error messages when an account is not found. This pattern correctly distinguishes between "not found" cases and genuine errors, improving the API's usability.

Optional style nitpick: The trailing comma in the format! macro on line 152 is valid but unconventional:

-        result = get_account(a, accounts_api)
-            .optional()?
-            .ok_or_else(|| not_found(format!("Account '{a}' not found.",)))?;
+        result = get_account(a, accounts_api)
+            .optional()?
+            .ok_or_else(|| not_found(format!("Account '{a}' not found.")))?;

crates/engine_types/src/crypto/elgamal.rs (1)

232-232: Consider debug level or summary logging for batch operations.

Logging every found balance at info level may generate excessive log volume during batch operations, especially with the new traffic-sim utility.

Consider one of these alternatives:

Option 1: Use debug level for individual items

-                info!(target: LOG_TARGET, "Found encrypted balance: {}", v);
+                debug!(target: LOG_TARGET, "Found encrypted balance: {}", v);

Option 2: Add a summary log after the loop completes

         }
+        
+        let found_count = results.iter().filter(|r| r.is_some()).count();
+        info!(target: LOG_TARGET, "Found {}/{} encrypted balances", found_count, results.len());
 
         Ok(results)

applications/tari_walletd/src/handlers/stealth_utxos.rs (1)

60-60: Consider extracting helper functions to reduce function length.

The function is quite long (128 lines). While the linear flow makes it readable, extracting the file-based and in-memory lookup logic into separate helper functions could improve maintainability.

For example, you could extract:

• spawn_file_based_lookup(...) for lines 112-146
• spawn_in_memory_lookup(...) for lines 153-161

+async fn spawn_file_based_lookup(
+    sdk: WalletSdk,
+    path: PathBuf,
+    view_key: ViewKey,
+    elgamal_proofs: Vec<_>,
+    value_range: RangeInclusive<u64>,
+) -> JoinHandle<anyhow::Result<Vec<u64>>> {
+    spawn_blocking(move || {
+        let mut file = fs::File::open(&path)
+            .map_err(|e| anyhow!("Unable to load value lookup file '{}': {e}", path.display()))?;
+        let mut lookup = IoReaderValueLookup::load(&mut file)?;
+        info!(
+            target: LOG_TARGET,
+            "Using value lookup table from file '{}' ({}-{}) for brute force balance lookup",
+            path.display(),
+            lookup.range().start(),
+            lookup.range().end()
+        );
+        
+        let start = value_range.start();
+        let end = value_range.end();
+        if start < lookup.range().start() || end > lookup.range().end() {
+            warn!(
+                target: LOG_TARGET,
+                "The requested value range ({}-{}) is outside the loaded value lookup table range ({}-{}). \
+                 This query may take excessive amount of time.",
+                start,
+                end,
+                lookup.range().start(),
+                lookup.range().end()
+            );
+        }
+        
+        sdk.viewable_balance_api().try_brute_force_commitment_balances(
+            &view_key.key,
+            elgamal_proofs.iter(),
+            value_range,
+            &mut lookup,
+        )
+    })
+}

crates/template_lib/src/models/stealth.rs (3)

33-42: Guard against negative revealed output amounts

Add a simple non-negative check to match inputs-side validation and avoid constructing invalid statements.

Apply:

 impl StealthOutputsStatement {
   /// Create a new output statement with no stealth outputs, only a revealed amount.
   pub fn new_revealed_only(amount: Amount) -> Self {
+      assert!(!amount.is_negative(), "Revealed output amount must be non-negative");
       Self {
           outputs: vec![],
           revealed_output_amount: amount,
           agg_range_proof: RangeProofBytes::empty(),
       }
   }
 }

---

95-97: Optional balance_proof: consider eliding nulls in JSON

If these structs are serialized to JSON anywhere, add serde skip to avoid emitting explicit nulls; wire format (borsh/proto) unaffected.

Apply:

-    #[cfg_attr(feature = "ts", ts(type = "{public_nonce: string, signature: string} | null"))]
-    pub balance_proof: Option<BalanceProofSignature>,
+    #[cfg_attr(feature = "ts", ts(type = "{public_nonce: string, signature: string} | null"))]
+    #[serde(skip_serializing_if = "Option::is_none")]
+    pub balance_proof: Option<BalanceProofSignature>,

---

101-111: Assert the “revealed-only” invariant locally

Add a debug assertion to ensure this constructor never sneaks in stealth I/O and keeps balance_proof None only in that case.

Apply:

 pub fn revealed_only(
     input_amount: Amount,
     output_amount: Amount,
     required_signer: RistrettoPublicKeyBytes,
 ) -> Self {
-    Self {
-        inputs_statement: StealthInputsStatement::new_revealed_only(input_amount, required_signer),
-        outputs_statement: StealthOutputsStatement::new_revealed_only(output_amount),
-        balance_proof: None,
-    }
+    let inputs_statement = StealthInputsStatement::new_revealed_only(input_amount, required_signer);
+    let outputs_statement = StealthOutputsStatement::new_revealed_only(output_amount);
+    debug_assert!(
+        inputs_statement.inputs.is_empty() && outputs_statement.outputs.is_empty(),
+        "revealed_only must have no stealth inputs/outputs"
+    );
+    Self {
+        inputs_statement,
+        outputs_statement,
+        balance_proof: None,
+    }
 }

Also, the struct docstrings above still say “must contain confidential outputs”; please update to reflect revealed-only allowance.

crates/p2p/src/conversions/transaction.rs (1)

823-824: Add a debug invariant on serialization symmetry

Ensure we never serialize a stealth transfer with missing proof unless it’s revealed-only.

Apply:

 impl From<tari_template_lib::models::StealthTransferStatement> for proto::transaction::StealthTransferStatement {
     fn from(value: tari_template_lib::models::StealthTransferStatement) -> Self {
+        let is_revealed_only =
+            value.inputs_statement.inputs.is_empty() && value.outputs_statement.outputs.is_empty();
+        let balance_proof_bytes = value.balance_proof.as_ref().map(|b| b.to_bytes()).unwrap_or_default();
+        debug_assert!(
+            (is_revealed_only && balance_proof_bytes.is_empty()) ||
+            (!is_revealed_only && !balance_proof_bytes.is_empty()),
+            "Invariant: balance_proof must be present unless revealed-only"
+        );
         Self {
             inputs_statement: Some(value.inputs_statement.into()),
             outputs_statement: Some(value.outputs_statement.into()),
-            balance_proof: value.balance_proof.as_ref().map(|b| b.to_bytes()).unwrap_or_default(),
+            balance_proof: balance_proof_bytes,
         }
     }
 }

crates/epoch_oracles/src/configured/real_time_ticker.rs (2)

66-75: Gate the “fast-forward to initial epoch” on self.epoch too.

Avoid needless emissions once self.epoch has already reached/passed initial_epoch.

-        if calculated_epoch < self.initial_epoch {
+        if calculated_epoch < self.initial_epoch && self.epoch < self.initial_epoch {
             let epoch = self.increment_epoch();
             let epoch_hash = calc_static_epoch_hash(epoch);
             return Poll::Ready(Some(EpochTickerData {
                 epoch,
                 epoch_hash,
                 done_for_now: false,
             }));
         }

---

164-177: Test relies on loop recompute; will stall without it.

With the fix to recompute calculated_epoch per tick, this test should pass. Without it, poll_tick never returns when base time > now.

Consider injecting a clock (trait or now_fn) into RealTimeEpochTicker so tests don’t depend on wall-clock timing.

utilities/traffic-sim/Cargo.toml (3)

10-11: Relax version pins to caret for compatibility.

Use caret constraints to pick up compatible bugfixes without manual bumps.

-clap = { version = "4.0", features = ["derive"] }
-tokio = { version = "1.0", features = ["rt-multi-thread", "macros"] }
+clap = { version = "4", features = ["derive"] }
+tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

---

15-15: Prefer rustls and disable reqwest default features.

Avoid platform OpenSSL issues and shrink dependency tree.

-reqwest = { workspace = true, features = ["json"] }
+reqwest = { workspace = true, default-features = false, features = ["json", "rustls-tls"] }

If the workspace sets reqwest TLS features globally, confirm no duplication/conflict.

---

19-19: Avoid hard pin on csv unless strictly required.

Use caret for patch updates; keeps reproducible yet flexible.

-csv = "1.4.0"
+csv = "1.4"

applications/tari_wallet_cli/src/command/transaction.rs (4)

253-256: Improve error context for missing owner key.

Include the fee account address to speed up debugging.

-    let owner_key_id = fee_account
-        .owner_key_id
-        .ok_or_else(|| anyhow!("Fee account does not have an owner key ID"))?;
+    let owner_key_id = fee_account
+        .owner_key_id
+        .ok_or_else(|| anyhow!("Fee account {} does not have an owner key ID", fee_account.component_address))?;

---

285-291: LGTM – explicit seal_signer and detect_inputs flags are correct.

Consider factoring common request fields to reduce duplication between dry-run and submit.

Also applies to: 297-302, 355-360, 366-371

---

325-328: Apply the same improved error context in manifest submit.

Mirror the enhanced message here for consistency.

-    let owner_key_id = fee_account
-        .owner_key_id
-        .ok_or_else(|| anyhow!("Fee account does not have an owner key ID"))?;
+    let owner_key_id = fee_account
+        .owner_key_id
+        .ok_or_else(|| anyhow!("Fee account {} does not have an owner key ID", fee_account.component_address))?;

---

445-445: Make input selection configurable.

Defaulting to PreferConfidential is fine, but expose a CLI flag to toggle selection for ops/debug.

Would you like me to add --input-selection {PreferRevealed|PreferConfidential|RevealedOnly|ConfidentialOnly}? I can wire it with clap and map to UtxoInputSelection.

crates/wallet/sdk/src/apis/stealth_transfer/error.rs (1)

5-5: LGTM – error context improved with Amounts.

Consider adding serde derives if this bubbles over API boundaries.

crates/wallet/sdk/src/apis/stealth_transfer/params.rs (1)

22-24: Clarify field-level documentation.

The comments on lines 22 and 23 are identical. Consider clarifying the distinction between fee_input_selection (for fee payment) and input_selection (for main transfer amounts) to improve code maintainability.

Apply this diff to improve the documentation:

-    /// Strategy for input selection
     pub fee_input_selection: UtxoInputSelection,
-    /// Strategy for input selection
+    /// Strategy for selecting inputs for the fee payment
+    pub fee_input_selection: UtxoInputSelection,
+    /// Strategy for selecting inputs for the transfer amount
     pub input_selection: UtxoInputSelection,

utilities/traffic-sim/src/sim.rs (2)

268-412: Consider refactoring for maintainability.

This function is 144 lines long and handles multiple concerns (checking balances, creating test coins, creating transfer statements, building transactions, submitting, and waiting for results). Consider extracting smaller helper methods for each major step to improve readability and testability.

---

286-286: Consider parameterizing the fund amount.

The fund amount is hardcoded to 10_000_000_000. Consider making this a parameter to the function for flexibility in different testing scenarios.

crates/wallet/sdk/src/apis/stealth_outputs.rs (1)

182-186: New create_lock API: useful, but consider RAII guard to avoid leaked locks on early returns.

Expose a small drop-guard (e.g., WalletLockDropGuard) that auto-releases if not finalized, and return it from create_lock to make flows exception-safe.

-    pub fn create_lock(&self) -> Result<WalletLockId, StealthOutputsApiError> {
-        let lock_id = self.store.with_write_tx(|tx| tx.locks_create())?;
-        Ok(lock_id)
-    }
+    pub fn create_lock(&self) -> Result<WalletLockDropGuard<'_, TStore>, StealthOutputsApiError> {
+        let lock_id = self.store.with_write_tx(|tx| tx.locks_create())?;
+        Ok(WalletLockDropGuard::new(self.store, lock_id))
+    }

Note: adjust call sites and provide finalize() to consume the guard.

applications/tari_indexer/src/rest_api/handlers/utxos.rs (2)

100-113: fetch_utxos migration looks correct; keep limit guard consistent with GET list.

The 1000 cap mirrors other handlers; consider extracting a shared const to avoid drift.

-    if req.tag_and_nonce_pairs.len() > 1000 {
+    const MAX_UTXO_BATCH: usize = 1000;
+    if req.tag_and_nonce_pairs.len() > MAX_UTXO_BATCH {
         return Err(ErrorResponse::bad_request("cannot query more than 1000 UTXOs"));
     }

---

115-132: New list_utxos endpoint: solid; unify limits via a shared constant.

Add a MAX_UTXO_PAGE_SIZE const and reuse across stream/fetch/list to prevent divergence.

-#[utoipa::path(get, path = "/utxos", description = "List full UTXO data")]
+const MAX_UTXO_PAGE_SIZE: u32 = 1000;
+#[utoipa::path(get, path = "/utxos", description = "List full UTXO data")]
 pub async fn list_utxos(
     Extension(context): Extension<HandlerContext>,
     Query(req): Query<ListUtxosRequest>,
 ) -> HandlerResult<Json<ListUtxosResponse>> {
-    if req.limit == 0 {
+    if req.limit == 0 {
         return Err(ErrorResponse::bad_request("limit must be greater than 0"));
     }
-    if req.limit > 1000 {
+    if req.limit > MAX_UTXO_PAGE_SIZE {
         return Err(ErrorResponse::bad_request("cannot query more than 1000 UTXOs"));
     }

Please confirm the store layer enforces resource scoping with from_id to prevent cross-resource leakage when a malformed from_id is provided.

integration_tests/tests/steps/wallet_daemon.rs (1)

128-135: Improve owner_key_id error message with account context.

The suggestion is valid and beneficial. The owner_key_id() method returns Option<KeyId>, which can be None even for valid accounts. While the account existence is already guarded at lines 111–114, a panic with the account name will aid debugging. Since account_name is available as a function parameter (line 106), the suggested refactor using unwrap_or_else() with context is an improvement over the generic error message.

- seal_signer: BranchAndKeyId::new(KeyBranch::Account, account.owner_key_id().expect("no owner key id")),
+ seal_signer: BranchAndKeyId::new(
+     KeyBranch::Account,
+     account
+         .owner_key_id()
+         .unwrap_or_else(|| panic!("Account {account_name} has no owner key id; cannot seal-sign")),
+ ),

utilities/generate_ristretto_value_lookup/src/main.rs (3)

115-117: Scratch-pad preallocation is ineffective

vec![Some(Vec::with_capacity(...)); num_threads] clones an empty Vec; clones lose the reserved capacity. Build each entry explicitly.

-    let mut scratch_pad = vec![Some(Vec::with_capacity(CHUNK_SIZE)); num_threads];
+    let mut scratch_pad: Vec<Option<Vec<[u8; 32]>>> =
+        (0..num_threads).map(|_| Some(Vec::with_capacity(CHUNK_SIZE))).collect();

---

148-153: Buffered writes for throughput

Writing 32 bytes per key is syscall-heavy. Wrap the file in a BufWriter with a large buffer.

Within main (near file creation):

-use std::{
-    fs,
-    io,
-    io::{stdout, Write},
-    time::{Duration, Instant},
-};
+use std::{
+    fs,
+    io,
+    io::{stdout, Write, BufWriter},
+    time::{Duration, Instant},
+};
...
-    let writer = fs::File::create(&dest_file)?;
+    let writer = BufWriter::with_capacity(1 << 20, fs::File::create(&dest_file)?); // 1 MiB buffer

No change needed to write_output_async signature since BufWriter implements Write.

---

18-18: Remove unused import

ValueLookupTable isn’t used.

-use tari_ootle_wallet_crypto::ValueLookupTable;

clients/tari_indexer_client/src/rest_api_client.rs (1)

170-176: get_utxos/list_utxos methods — LGTM

POST to utxos/fetch and GET to utxos are correct and consistent with handlers. Consider surfacing a helper to clamp client-side limit to 1000 to fail fast, but server validates already.

crates/wallet/sdk/src/models/lock_guard.rs (1)

11-14: Guard owns the store; disarm drops it — add must_use and a way to recover the store.

Owning TStore means callers lose it once passed in; disarm() also discards it. Add #[must_use] to the guard and expose into_inner() so callers can reclaim the store when disarming.

- pub struct WalletLockDropGuard<TStore: WriteableWalletStore> {
+ #[must_use]
+ pub struct WalletLockDropGuard<TStore: WriteableWalletStore> {
@@
 impl<TStore> WalletLockDropGuard<TStore>
 where TStore: WriteableWalletStore
 {
@@
     pub fn disarm(mut self) {
         self.store = None;
     }
+
+    /// Consume the guard and recover the owned store without unlocking.
+    pub fn into_inner(mut self) -> Option<TStore> {
+        self.store.take()
+    }
 }

Also applies to: 30-33

crates/wallet/sdk/src/apis/stealth_transfer/api.rs (1)

135-141: Error variant naming consistency (optional).

RevealedOnly returns InsufficientFunds with revealed-specific details, while other branches sometimes use InsufficientRevealedFunds. Consider standardizing the variant for clearer UX.

crates/wallet/sdk/src/apis/confidential_transfer.rs (1)

131-141: Use available_revealed_funds to avoid locking already-reserved funds.

PreferRevealed uses src_vault.revealed_balance rather than the computed available_revealed_funds; this can over-request and fail later. Use the available figure.

-            UtxoInputSelection::PreferRevealed => {
-                let revealed_to_spend = cmp::min(src_vault.revealed_balance, spend_amount);
+            UtxoInputSelection::PreferRevealed => {
+                let revealed_to_spend = cmp::min(available_revealed_funds, spend_amount);

applications/tari_walletd/src/handlers/accounts.rs (3)

1083-1088: Avoid magic number for batch size

Replace hard-coded 16 with a named constant for clarity and central control.

Apply:

-    if req.requests.len() > 16 {
+    const MAX_STEALTH_STATEMENT_REQUESTS: usize = 16;
+    if req.requests.len() > MAX_STEALTH_STATEMENT_REQUESTS {

If you prefer, hoist the constant near the top of the file.

---

1168-1179: Deterministic ordering for signing_keys

HashSet iteration order is nondeterministic. For stable client UX and reproducible responses, preserve insertion order.

Option A (preferred): use IndexSet.

-    let mut required_signers = HashSet::new();
+    use indexmap::IndexSet;
+    let mut required_signers = IndexSet::new();
...
-    Ok(AccountsCreateStealthTransferStatementResponse {
-        statements,
-        lock_id,
-        signing_keys: required_signers.into_iter().collect(),
-    })
+    Ok(AccountsCreateStealthTransferStatementResponse {
+        statements,
+        lock_id,
+        signing_keys: required_signers.into_iter().collect(), // now deterministic
+    })

Option B: collect to Vec and sort by (branch, key_id).

---

1094-1096: Avoid shadowing req inside the loop

Shadowing the outer request parameter with for req in req.requests harms readability.

Rename the loop variable, e.g.:

-    for req in req.requests {
+    for stm_req in req.requests {

clients/wallet_daemon_client/src/types.rs (1)

118-134: TransactionSubmitRequest surface looks correct

seal_signer/other_signers/lock_ids fields reflect server changes. Consider TS hint for lock_ids if WalletLockId is not already mapped to number[] in TS.

If needed, annotate:

 pub struct TransactionSubmitRequest {
     pub transaction: UnsignedTransaction,
     pub seal_signer: BranchAndKeyId,
     pub other_signers: Vec<BranchAndKeyId>,
@@
-    pub lock_ids: Vec<WalletLockId>,
+    #[cfg_attr(feature = "ts", ts(type = "Array<number>"))]
+    pub lock_ids: Vec<WalletLockId>,
 }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

bindings/src/types/wallet-daemon-client/StealthUtxosDecryptValueRequest.ts (1)

9-10: Breaking change: maximum_expected_value now required, but call sites still pass null.

The past review correctly identified that removing nullability from maximum_expected_value while keeping minimum_expected_value nullable creates both a type contract violation (DecryptUtxoBalance.tsx line 48 still passes null) and an unexplained asymmetry with similar types like ConfidentialViewVaultBalanceRequest.

Since this is a generated file, the fix must be applied to the Rust source. Given the feat!: breaking change marker in the PR title, ensure:

1. All downstream call sites are updated to provide a concrete value
2. The asymmetry between min/max nullability is intentional and documented
3. A migration guide addresses this breaking API change

The verification script from the past review remains valid for confirming all call sites have been updated.

clients/wallet_daemon_client/src/types.rs (1)

1194-1194: Field renamed from balances to values - frontend update required.

This field rename requires corresponding updates in the TypeScript UI code. As noted in the previous review, DecryptUtxoBalance.tsx still accesses .balances instead of .values.

applications/tari_indexer/src/storage_sqlite/reader.rs (1)

563-606: Burnt UTXOs should also be filtered in utxos_list query.

As noted in the previous review, Line 574 currently only filters is_spent = false but should also exclude burnt UTXOs (is_burnt = false) for consistency with other unspent UTXO queries in this file (e.g., utxos_get_unspent_by_public_nonce_and_tag at lines 638-639).

Apply this diff:

         let mut query = utxos::table
             .filter(utxos::resource_address.eq(resource_address.to_string()))
             .filter(utxos::is_spent.eq(false))
+            .filter(utxos::is_burnt.eq(false))
             .into_boxed();

applications/tari_validator_node/src/cli.rs (1)

27-30: Remove unused ConfigPath import.

ConfigPath isn’t referenced in this file. Drop it to keep imports clean.

-use tari_common::{
-    configuration::{ConfigOverrideProvider, Network as L1Network},
-    ConfigPath,
-};
+use tari_common::configuration::{ConfigOverrideProvider, Network as L1Network};

utilities/generate_ristretto_value_lookup/src/main.rs (2)

73-77: Compile risk: tokio runtime metrics require tokio_unstable; use a stable fallback.

Replace metrics-based worker count with std::thread::available_parallelism() and ensure at least 1.

Apply:

-    let jobs = cli
-        .jobs
-        .unwrap_or_else(|| tokio::runtime::Handle::current().metrics().num_workers());
+    let jobs = cli.jobs.unwrap_or_else(|| {
+        std::thread::available_parallelism()
+            .map(|n| n.get())
+            .unwrap_or(1)
+    });

---

168-183: Progress denominator off by one in printed total.

Total values = max - min + 1, but the print uses max - min.

Apply:

-                "{:.1}% ETA: {}. {}/{} values generated in {}",
+                "{:.1}% ETA: {}. {}/{} values generated in {}",
                 (completed as f64 / (max - min + 1) as f64) * 100.0,
                 humantime::format_duration(est_time),
                 completed,
-                max - min,
+                max - min + 1,
                 humantime::format_duration(Duration::from_secs(elapsed.as_secs()))

applications/tari_walletd/web_ui/src/services/api/hooks/useAccounts.ts (1)

161-163: Use strict equality for XTR check

Change == to === to avoid type coercion surprises.

-          // For simplicity, we'll use prefer revealed for fees whenever a non-XTR stealth transfer is made
-          fee_input_selection: params.resource_address == XTR ? params.input_selection : "PreferRevealed",
+          // For simplicity, we'll use PreferRevealed for fees whenever a non‑XTR stealth transfer is made
+          fee_input_selection: params.resource_address === XTR ? params.input_selection : "PreferRevealed",

#!/bin/bash
# Verify no other '== XTR' checks remain
rg -nP --type=ts -C2 '\b==\s*XTR\b'

applications/tari_walletd/src/handlers/accounts.rs (3)

1103-1104: Validate resource is stealth before proceeding

Still missing the stealth-type guard. Generate a clear error early to avoid confusing decode failures later.

Apply this diff:

         let resource = sdk.substate_api().fetch_resource(req.resource_address).await?;
+        if !resource.resource_type().is_stealth() {
+            return Err(invalid_params(
+                "resource_address",
+                Some(format!(
+                    "Resource is not a stealth resource (type: {})",
+                    resource.resource_type()
+                )),
+            ));
+        }

---

1121-1127: Must sign with account key when revealed funds come FromBucket as well

Condition still omits revealed funds provided via FromBucket.

Apply this diff:

-        let must_sign_with_account_key = inputs.as_ref().is_some_and(|i| i.revealed.is_positive());
+        let must_sign_with_account_key =
+            inputs.as_ref().is_some_and(|i| i.revealed.is_positive()) ||
+            req.input_selection.as_from_bucket().is_some_and(|a| a.is_positive());

---

1152-1163: Avoid checked_add_positive with zero addend for input_revealed_amount

Zero addend causes a spurious error; compute conditionally.

Apply this diff:

-                input_revealed_amount: req
-                    .input_selection
-                    .as_from_bucket()
-                    .unwrap_or(Amount::zero())
-                    .checked_add_positive(inputs.as_ref().map(|i| i.revealed).unwrap_or(Amount::zero()))
-                    .ok_or_else(|| {
-                        invalid_params(
-                            "input_revealed_amount",
-                            Some("input revealed amount overflowed or was negative"),
-                        )
-                    })?,
+                input_revealed_amount: {
+                    let mut total = req.input_selection.as_from_bucket().unwrap_or(Amount::zero());
+                    if let Some(i) = inputs.as_ref() {
+                        if i.revealed.is_positive() {
+                            total = total.checked_add_positive(i.revealed).ok_or_else(|| {
+                                invalid_params(
+                                    "input_revealed_amount",
+                                    Some("input revealed amount overflowed"),
+                                )
+                            })?;
+                        }
+                    }
+                    total
+                },

crates/wallet/sdk/src/models/wallet_transaction.rs (1)

51-57: Add documentation for these public helper methods.

These methods are part of the public API but lack doc comments. Consider adding documentation to clarify the distinction between "any acceptance" (including partial fee-only acceptance) and full acceptance.

Apply this diff to add documentation:

+    /// Returns `true` if the transaction has been accepted in any form,
+    /// including full acceptance or fee-only acceptance.
     pub fn is_any_accept(&self) -> bool {
         matches!(self, TransactionStatus::Accepted | TransactionStatus::OnlyFeeAccepted)
     }

+    /// Returns `true` only if the transaction has been fully accepted.
     pub fn is_accepted(&self) -> bool {
         matches!(self, TransactionStatus::Accepted)
     }

crates/engine_types/src/crypto/elgamal.rs (1)

232-232: Consider debug level for balance discovery logs.

The info log at line 232 will fire for each balance found during brute force decryption. If this method is frequently called with large batches, log verbosity could become substantial.

Consider using debug! instead of info! unless operational visibility at the info level is specifically required. Additionally, verify that logging actual balance values is acceptable from a privacy/security perspective in production environments.

Apply this diff to reduce log verbosity:

-                info!(target: LOG_TARGET, "Found encrypted balance: {}", v);
+                debug!(target: LOG_TARGET, "Found encrypted balance: {}", v);

applications/tari_wallet_cli/src/command/transaction.rs (1)

253-255: Owner key derivation is correct.

The error handling properly guards against missing owner key IDs. However, this exact pattern is duplicated in handle_submit_manifest (lines 325-327).

Consider extracting a helper function to reduce duplication:

async fn get_fee_account_owner_key_id(
    client: &mut WalletDaemonClient,
    fee_account_arg: Option<ComponentAddressOrName>,
) -> Result<KeyId, anyhow::Error> {
    let fee_account = if let Some(fee_account_name) = fee_account_arg {
        client.accounts_get(fee_account_name).await?.account
    } else {
        client.accounts_get_default().await?.account
    };
    
    fee_account
        .owner_key_id
        .ok_or_else(|| anyhow!("Fee account does not have an owner key ID"))
}

Then use it in both functions:

let owner_key_id = get_fee_account_owner_key_id(client, common.fee_account.clone()).await?;

applications/tari_walletd/src/handlers/stealth_utxos.rs (1)

181-181: Consider renaming for consistency.

The variable is named balances while the response field is values (line 186). Consider renaming the variable to values for consistency with the public API.

-    let balances = handle.await??;
+    let values = handle.await??;

Then update line 186:

-        values: proofs.into_keys().zip(balances).collect(),
+        values: proofs.into_keys().zip(values).collect(),

applications/tari_walletd/web_ui/src/routes/StealthUtxoList/StealthUtxoList.tsx (1)

45-45: Good change: Dynamic divisibility with safe fallback.

The derivation correctly uses the resource's divisibility property with a safe fallback to 6 when balance data is unavailable. This enables proper formatting for resources with different decimal places.

Optionally, consider adding a comment explaining why 6 is the default (e.g., XTR's divisibility):

+  // Default to 6 (XTR divisibility) when resource balance is unavailable
   const divisibility = resourceBalance ? resourceBalance.divisibility : 6;

crates/engine_types/src/stealth/transfer.rs (1)

59-68: Consider refining the error message phrasing.

The security logic is sound — requiring None balance proof when there are no stealth inputs/outputs prevents leaking the secret nonce. However, the error message ending with "None is required" is slightly awkward.

Consider this minor phrasing improvement:

-                details: "Balance proof signature verification failed for revealed amount. This indicates that the \
-                          transfer statement provided a balance proof when there are no stealth inputs or outputs, \
-                          None is required."
+                details: "Balance proof must be None when there are no stealth inputs or outputs (providing a proof \
+                          would leak the secret nonce)."

crates/wallet/sdk/src/models/lock_guard.rs (1)

11-33: Consider adding documentation for the public API.

The public struct and methods would benefit from doc comments explaining:

• The purpose and usage pattern of the guard
• When and why to call disarm()
• Whether the guard is Send/Sync and any thread-safety considerations

applications/tari_validator_node/src/cli.rs (1)

108-116: Extract repeated peer_seeds.join() to reduce duplication.

The key path format is correct as-is (matches TOML structure: [nextnet.p2p.seeds], etc.). However, the duplication of self.peer_seeds.join(",") at lines 111 and 115 should be factored out:

         if !self.peer_seeds.is_empty() {
+            let seeds = self.peer_seeds.join(",");
             overrides.push((
                 format!("{}.peer_seeds", PeerSeedsConfig::main_key_prefix()),
-                self.peer_seeds.join(","),
+                seeds.clone(),
             ));
             overrides.push((
                 format!("{}.{}.peer_seeds", network, PeerSeedsConfig::main_key_prefix()),
-                self.peer_seeds.join(","),
+                seeds,
             ));
         }

Note: The same pattern exists in applications/tari_indexer/src/cli.rs (lines 101–106) and should be refactored identically.

utilities/generate_ristretto_value_lookup/src/main.rs (3)

71-78: Buffer and preallocate the output file to reduce blocking and IO syscalls.

Large numbers of 32‑byte writes on a std::fs::File in an async context can block the runtime thread and be slow.

Apply:

-    let writer = fs::File::create(&dest_file)?;
+    let mut file = fs::File::create(&dest_file)?;
+    // Best-effort preallocation; ignore if filesystem doesn't support it
+    let _ = file.set_len(file_size as u64);
+    let writer = std::io::BufWriter::with_capacity(8 * 1024 * 1024, file);

---

28-37: Speed up validation reads with a buffered reader (optional).

Validation iterates the entire file; using BufReader reduces syscalls and wall time.

Apply:

-        let mut file = fs::File::open(&dest_file)?;
-        let mut lookup = tari_ootle_wallet_crypto::IoReaderValueLookup::load(&mut file)?;
+        let file = fs::File::open(&dest_file)?;
+        let mut reader = std::io::BufReader::with_capacity(8 * 1024 * 1024, file);
+        let mut lookup = tari_ootle_wallet_crypto::IoReaderValueLookup::load(&mut reader)?;

---

95-100: Optional: flush at the end of write_output_async.

Be explicit to surface IO errors early.

Add before returning Ok(()):

writer.flush()?;

applications/tari_walletd/web_ui/src/routes/FlowEditor/FlowEditor.tsx (1)

211-213: Preempt UI to avoid runtime throw when owner_key_id is missing

Good guard. Consider disabling submit (and surfacing a helper text alongside the account selector) if account.account.owner_key_id is null, rather than throwing at execution time. This avoids user-facing exceptions.

crates/template_lib/src/models/stealth.rs (1)

101-112: Enforce value conservation in revealed-only constructor

Add a simple assert to ensure input_amount equals output_amount for revealed-only statements to prevent accidental mismatches at construction time. Ledger will enforce this later, but failing fast here reduces footguns.

 pub fn revealed_only(
     input_amount: Amount,
     output_amount: Amount,
     required_signer: RistrettoPublicKeyBytes,
 ) -> Self {
+    assert!(
+        input_amount == output_amount,
+        "Revealed-only stealth transfer must conserve value (inputs == outputs)"
+    );
     Self {
         inputs_statement: StealthInputsStatement::new_revealed_only(input_amount, required_signer),
         outputs_statement: StealthOutputsStatement::new_revealed_only(output_amount),
         balance_proof: None,
     }
 }

applications/tari_walletd/src/handlers/transaction.rs (1)

256-260: Update comment to reflect locks, not proofs

Comment still references “proofs table”. Please update to “locks”.

-        // update the proofs table with the corresponding transaction hash
+        // update the locks with the corresponding transaction ID for later finalization/release

applications/tari_walletd/src/handlers/accounts.rs (1)

1105-1106: Reject zero-output requests early

Guard against no-op statements to avoid needless locking/work.

Apply this diff:

         let amount_to_spend = req.total_output_amount();
+        if amount_to_spend.is_zero() {
+            return Err(invalid_params("outputs", Some("total output amount must be > 0")));
+        }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro